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Introduction 

The final design for an effective Comet/Asteroid Protection System (CAPS) will likely come after a 
number of competing designs have been simulated and evaluated. Because of the large number of design 
parameters involved in a system capable of detecting an object, accurately determining its orbit, and 
diverting the impact threat, a comprehensive simulation environment will be an extremely valuable tool 
for the CAPS designers. A successful simulation/design tool will aid the user in identifying the critical 
parameters in the system and eventually allow for automatic optimization of the design once the relation- 
ships of the key parameters are understood. 

A CAPS configuration will consist of space-based detectors whose purpose is to scan the celestial 
sphere in search of objects likely to make a close approach to Earth and to determine with the greatest 
possible accuracy the orbits of those objects. Other components of a CAPS configuration may include 
systems for modifying the orbits of approaching objects, either for the purpose of preventing a collision or 
for positioning the object into an orbit where it can be studied or used as a mineral resource. The Syner- 
gistic Engineering Environment (SEE) is a space-systems design, evaluation, and visualization software 
tool being leveraged to simulate these aspects of the CAPS study. The long-term goal of the SEE is to 
provide capabilities to allow the user to build and compare various CAPS designs by running end-to-end 
simulations that encompass the scanning phase, the orbit determination phase, and the orbit modification 
phase of a given scenario. 

Herein, a brief description of the expected simulation phases is provided, the current status and avail- 
able features of the SEE software system is reported, and examples are shown of how the system is used 
to build and evaluate a CAPS detection design. Conclusions and the roadmap for future development of 
the SEE are also presented. 

Comet/Asteroid Protection System Simulations 

The scanning phase of the Comet/Asteroid Protection System (CAPS) activity is referred to in the 
Synergistic Engineering Environment (SEE) as the “Survey Mode” simulation. In this mode a configura- 
tion of space-based detectors is scanning the celestial sphere, identifying and cataloguing potentially 
hazardous objects, and performing preliminary orbit determination. The object of the survey simulation is 
to evaluate the effectiveness of a given telescope configuration and scanning pattern in identifying poten- 
tially hazardous near-Earth objects (NEOs). 

The process of evaluating the ability of the CAPS system to properly identify the orbit of an object on 
a collision course with Earth is referred to as the “precision orbit determination” (POD) simulation. In this 
mode, one or more simulated NEOs will be placed on a collision course with Earth. The results of these 
simulations will show how well these orbits were able to be determined at a selected time prior to impact, 


^Chapter nomenclature available in chapter notes, p. 217. 
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or the results will return a warning time that indicates how many days prior to impact the system was able 
to determine that the object was on a collision course. 

The process of using the CAPS configuration to evaluate the composition of a given NEO is referred 
to as the “physical characteristics” simulation. In this mode the simulation will determine the ability of 
the system to report what the object is made of in order to determine its value as a resource. 

Modeling the procedures for averting an impact is referred to as the “orbit modification” simulation. 
The orbit modification procedures can be divided into two types: deflection mode and resource utiliza- 
tion mode. In both cases the simulation will determine the ability of a given CAPS configuration to make 
desired orbital adjustments to an approaching object. A deflection case will model the modification of an 
NEO orbit from an Earth- impacting trajectory to a nonimpacting trajectory. The resource utilization case 
is not restricted to impacting NEOs and will have additional constraints on the target orbit (e.g., that the 
new orbit must leave the object more easily accessible for rendezvous missions). 

The near-term goals of the SEE CAPS module were to support survey and impact simulations and 
schedule the physical characteristics and orbit modification simulations for longer term development. 

Software Architecture and Current Feature Set 

The SEE is a cross-platform application that may be run on Windows, IRIX, and Linux operating sys- 
tems. The main feature of the SEE is the ability to create and view objects in orbit or on the surface of 
planets and moons in the solar system. The user interface is designed to allow ease of navigation to 
points and times of interest in the three-dimensional (3-D) scene. All models including both planets and 
spacecraft are rendered by default at their actual scales. An interactive scaling command allows the user 
to create views in which all objects in the scene are to be visible regardless of size. 

Running a simulation generally involves creating SEE objects to represent all of the real objects being 
simulated (e.g., planets, moons, telescopes) and then populating the SEE objects with appropriate 
parameters (e.g., orbital parameters, detector performance models). An SEE object refers to an entity in 
the simulation that has properties that can be updated as the simulation progresses. The simulation time is 
controlled by an event loop, which will cause each of the SEE objects to update its time dependent 
parameters whenever the current simulation time is changed. The output of the simulation can be in the 
form of an interactive graphics window that shows the geometry of the scene for a given simulation time, 
or in data plots, data files, and reports describing the outcome of the run. Figure 1 shows a control flow 
diagram of an impact analysis loop connected to the main application. 

In the current revision of the SEE application, the user must launch the program in an interactive 
mode; that is, launching the application brings up an application window with graphical user interface 
(GUI) components. The user must create the simulation objects by adding various craft and minor planets 
or other natural objects using the GUI or by loading previously saved versions of these objects from files. 
Once created, the interactive mode will allow the user to vary the current simulation time using a graphi- 
cal time controller. Once launched, however, the SEE will also support noninteractive analysis by 
allowing the user to select from a list of data-generating routines such as a survey analysis. An analysis 
wizard will guide the user through the process of inputting parameters required to run a given analysis, 
always including a start time, stop time, and time step at which to record data. When the user accepts the 
analysis parameters and closes the wizard, the event loop is controlled automatically for the duration of 
the analysis. The event loop controller is responsible for changing the simulation time to the 
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Assumptions 

1) Solar system software exists: 

user defines planets and moons 

2) User can define asteroids: 
position, trajectory 

3) User can define spacecraft: 
orbit- or planet-based 

4) User can define detectors: 
field-of-view, capabilities, math 
model, restrictions, motions, 
exclusion zones 


Steps 

1) Setup solar system 

2) Define detectors 

3) Define asteroid with impact trajectory 

a) provide date of collision 

b) assume centered on Earth 

c) specify orbital elements 

d) define data such as albedo 
and size 

4) Define delta T offset in the past relative 
to collision 


Time in SEE is independent of CAPS 
time but is aware of latest data time 
stamp from CAPS data engine 


Plane of data showing convergence 
ellipse and latest orbit of asteroid 


Figure 1. SEE CAPS module control flow. 
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analysis start time. The controller then polls the SEE objects for data needed for the analysis, processes 
and saves the data, and advances the simulation time by one analysis time step. The process completes 
when the analysis stop time is reached. Data files and summary reports containing the results of the 
simulation can be viewed once the analysis is completed. All interactive navigation controls (except for 
the time controls) and scaling controls are active and available to the user while the analysis is underway. 

The currently implemented features of the SEE support the survey mode simulation and can also 
be used in the preparation of POD simulations. The survey mode simulation utilizes a helper applica- 
tion called the CAPS Coverage/Sensitivity Tool. A brief review of those capabilities is described 
subsequently. 

SEE and The Coverage/Sensitivity Tool Survey Mode Capabilities 

The SEE survey tools comprise features within the main SEE application and a separate coverage 
visualization application called the CAPS Coverage/Sensitivity Tool. The Coverage/Sensitivity Tool is 
used to gain insight into the success of a survey pattern with respect to total coverage and measured 
signal-to-noise (S/N) ratios for approaching objects at a uniform target distance without modeling the 
flight paths of those objects. The SEE application can then be used to evaluate the survey program 
against an asteroid/comet data set in which the motion of both the NEOs and the telescopes is modeled. 
A future goal of this project is to merge the features of the CAPS Coverage/Sensitivity Tool directly into 
the SEE main execution environment. 

The CAPS Coverage/Sensitivity Tool 

Overview. Placement of the CAPS survey telescopes will be influenced by the need to efficiently survey 
the celestial sphere at the desired target radius and the need to maximize the S/N ratio for the observed 
objects. In this section, a description is given of the CAPS Coverage/Sensitivity Tool and the simplified 
coverage/sensitivity analyses that have been performed to test the software and begin to understand the 
system tradeoffs regarding placement of CAPS detection assets. The input to the CAPS Coverage/ 
Sensitivity Tool is a schedule of telescope positions and bore sight direction vectors. The output of the 
tool is an interactive 3-D visualization of the coverage and sensitivity results. This tool facilitates a trade- 
off study among architectures and scanning strategies. The time dependent 3-D animations in the CAPS 
analysis module are useful for refining scanning strategies. 

For this analysis the position and bore sight data for the scanning telescopes were generated using the 
commercially available Satellite Tool Kit (STK) space system modeling software. The format of the 
position and bore sight data are straightforward ASCII file listing times, positions, and direction vectors 
for each scope. This file can also be generated using standard spreadsheet software or other tools capable 
of saving the data in ASCII format. STK was used here instead of the SEE because this analysis took 
place prior to completion of the SEE software. Once the schedule file is generated, the user may import 
these data, specify the telescope design parameters, and run the analysis (figs. 2 and 3). After the analysis 
is run, the user may adjust various rendering properties (fig. 4). The user can display the data as a time 
dependent animation or control the time manually. The mouse can be used to control the vantage point of 
the data visualization. 

Coverage analysis approach. Coverage analysis is accomplished by choosing a radius, such as 7 astro- 
nomical units (au), and examining how well a scanning strategy covers the heliocentric sphere of that 
radius. In the analysis, one measures where and how often the viewing frusta of the scanning telescopes 
intersect a given heliocentric sphere. To accomplish this, the sphere is “pixelized” using the algorithm in 
reference 1. Each pixel represents an approximately equal area region of the sphere (fig. 5). 
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Figure 2. CAPS coverage/sensitivity tool, time inputs. 



Figure 3. Telescope and NEO data input. 
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Figure 4. Rendering options. 



Figure 5. “Pixelizing” the celestial sphere. 
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The area surrounding a pixel is colored according to how often that pixel is viewed by the scanning 
telescopes. Initially, each pixel is colored blue to represent an unscanned pixel. A scanned pixel is col- 
ored from green to red, a green pixel having been scanned precisely once and a red repeatedly scanned 
five or more times. In this way, one can differentiate which portions of the sphere are scanned or over- 
scanned. For example, in figure 5 one sees the reddish-green bands where the polar and equatorial scopes 
overlap in their scans. One might also note that there is a scattering of unscanned (blue) pixels. This is 
due to the fact that the displayed scanning strategy allowed for absolutely no overlap in frames. Precision 
errors likely caused these pixels to lie just outside the scanning pattern of the frustum. 

The STK toolkit was used to produce 29 days of position and bore sight data for four lunar-based tele- 
scopes. Figure 6 shows a 1.2-au heliocentric sphere (semitransparent) and the viewing frusta of the four 
telescopes as seen from slightly above the ecliptic plane (in light blue). Figure 7 gives a zenith view and 
figure 8 gives a view from near Earth (slightly above the ecliptic). 

Coverage analysis results. For long-period comets (LPCs), coverage for the four-telescope, lunar-based 
architecture was tested on a 7-au heliocentric sphere with a 90° solar exclusion half-angle. The analysis 
was repeated with a 5° solar exclusion half-angle so that one may consider the scanning strategy under the 
assumption that some idea or device may eventually allow for such an improvement. 

For near-Earth asteroids (NEAs), coverage was tested on heliocentric spheres of radii 2, 1.2, and 
0.8 au with a solar exclusion half-angle of 45°. Once again, the analysis was repeated with a 5° solar 
exclusion half-angle. Of particular interest in these cases are the near-Earth views as they describe cover- 
age for objects that are 1 or 0.2 au from Earth. 



Figure 6. Telescope placement relative to a 1.2-au heliocentric sphere. 



Day 0 Day 1 0 Day 20 Day 29 

Figure 7. Zenith view of a 1.2-au heliocentric sphere. 
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Day 0 Day 10 Day 20 Day 29 

Figure 8. Near-Earth view of a 1.2-au heliocentric sphere. 

Tables 1 and 2 give the percentage of the sphere covered by the scanning strategy. It also indicates 
what percentage of the sphere received single or multiple coverage. It is clear from the percent coverage 
shown in the tables that solar exclusion is the primary factor for a lunar-based architecture. If one is to 
achieve a nearly complete scan in 30 days, then either the solar exclusion angle must be reduced or more 
telescopes are needed in some heliocentric orbit. The multiple coverage in this simple scanning strategy 
is surprisingly low. One would expect some double coverage if frames are to overlap by a few pixels. 
Employing a more sophisticated scanning algorithm can reduce the triple (and greater) coverage. One 
also expects to see some overcoverage on a lunar-based architecture as lunar months overlap, as they do 
in a 29-day scan. 


Table 1. Coverage Analysis With a 90° (7 au only) or 45° Solar Exclusion Half- Angle 


Radius of 
sphere, au 

Coverage, 

percent 

Single 

coverage, 

percent 

Double 

coverage, 

percent 

Triple 

coverage, 

percent 

Quadmple 

coverage, 

percent 

Over- 
coverage 
(5 or more), 
percent 

7 

43.2 

24.2 

11.8 

4.2 

1.4 

1.6 

2 

72.4 

37.8 

21.1 

8.2 

2.5 

2.8 

1.2 

58.8 

29.8 

17.5 

7.4 

2.0 

2.1 

0.8 

33.6 

18.3 

10.6 

3.6 

1.0 

0.1 


Table 2. Coverage Analysis With a 5° Solar Exclusion Half- Angle 


Radius of 
sphere, au 

Coverage, 

percent 

Single 

coverage, 

percent 

Double 

coverage, 

percent 

Triple 

coverage, 

percent 

Quadmple 

coverage, 

percent 

Over- 
coverage 
(5 or more), 
percent 

7 

99.8 

56.2 

27.7 

9.6 

3.0 

3.3 

2 

99.2 

57.5 

26.9 

9.4 

2.6 

2.9 

1.2 

97.8 

59.0 

25.8 

8.8 

2.1 

2.1 

0.8 

95.0 

64.4 

23.8 

5.4 

1.2 

0.1 
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Figures 9 through 12 give the visual representation of this analysis. Screen shots were taken from 
zenith, nadir, near-Earth, and the opposing far side (see figs. 7 and 8). The reddish-green bands in each of 
these images identify the overlap between two scanning telescopes. The reddish-green sector in the near- 
Earth (upper hemisphere) and far side (lower hemisphere) identify the overlap is scanning due to lunar 
orbit. Also, note the gap in coverage seen in the nadir views of the 1.2 and 0.8 au spheres that is also 
attributable to the lunar orbit. Either a modification in the scanning strategy is needed or one must accept 
a scanning period of greater than 29 days. 

Sensitivity analysis approach. A sensitivity analysis is performed in a fashion similar to the coverage 
analysis described previously. First, a heliocentric sphere is chosen and pixelized. For each pixel 
scanned by a telescope, the signal-to-noise (S/N) ratio is computed based on a user input set of telescope 
parameters. Analysis of the survey telescope design with blur centroiding incorporated demonstrated that 
the S/N ratio for each scan can be reduced to 3.6 and still provide positive indication of a target. The area 
representing that pixel is then colored according to the value of the S/N ratio. Values of 1 or less are 
colored gray with lighter shades close to 1 and darker shades close to 0. Ratios greater than 1 and less 
than 3.6 are colored on a continuous scale between red and green. Values near 1 are colored red and 
values near 3.6 are green. Ratios greater than 3.6 are also colored green. If a pixel is scanned multiple 
times, then the largest S/N ratio found for that pixel is used. 

Sensitivity analysis results. For all cases, the telescope was assumed to have an optical diameter of 3.2 m 
with quantum and optical efficiencies of 0.8. The integration time for the LPC is assumed to be 15 s. An 
integration time of 0.375 s is assumed for NEAs. 

Tables 3 and 4 give the percentage of the sphere scanned within a given range of sensitivity, or S/N 
ratio. The sensitivity for LPCs is well within the tolerance limit of 3.6. 

Table 3. Sensitivity Analysis With a 90° (7 au only) or 45° Solar Exclusion Half- Angle 


Radius of 
sphere, au 

S/N >3.6, 
percent 

1.0 < S/N <3.6, 
percent 

S/N < 1.0, 
percent 

7 

43.2 

0 

0 

2 

0 

7.5 

64.9 

1.2 

4.7 

54 

0 

0.8 

3.5 

30.3 

0 


Table 4. Sensitivity Analysis With a 5° Solar Exclusion Half-Angle 


Radius of 
sphere, au 

S/N >3.6, 
percent 

1.0 < S/N <3.6, 
percent 

S/N < 1.0, 
percent 

7 

99.8 

0 

0 

2 

0 

7.5 

91.7 

1.2 

4.7 

93.1 

0 

0.8 

3.8 

91.1 

0.1 


For NEAs, coverage was tested on heliocentric spheres of radii 2, 1.2, and 0.8 au with a solar exclu- 
sion half-angle of 45°. The object was assumed to be 50 m in diameter with an albedo of 0.02. As 
before, the analysis was repeated with a 5° solar exclusion half-angle. A schematic of the orbits assumed 
for NEA sensitivity analysis is shown in figure 13. 
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Zenith Nadir Near Earth Far side 




Figure 9. Coverage of a 7-au heliocentric sphere with 90° half-angle (top) and 5° half-angle (bottom). 


Zenith 




Nadir 


Near Earth 


Far side 




Figure 10. Coverage of a 2-au heliocentric sphere with 45° half-angle (top) and 5° half-angle (bottom). 
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Figure 11. Coverage of a 1.2-au heliocentric sphere with 45° half-angle (top) and 5° half-angle (bottom). 



Zenith 


Nadir 


Near Earth 


Far side 




Figure 12. Coverage of a 0.8-au heliocentric sphere with 45° half-angle (top) and 5° half-angle (bottom). 
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0.8 au sphere 


Near-Earth view 



au sphere 


Figure 13. Orbit diagram for near-Earth asteroid sensitivity analysis. 



Zenith Nadir Near Earth Far side 



Figure 14. Sensitivity for a 7-au heliocentric sphere with 90° half-angle (top) and 5° half-angle (bottom). 


For LPCs, sensitivity for the four-telescope, lunar-based architecture was tested on a 7-au heliocentric 
sphere with a 90° solar exclusion half-angle. The object was assumed to be 1000 m in diameter with an 
albedo of 0.02. The analysis was repeated with a 5° solar exclusion half-angle so that one may consider 
the scanning strategy under the assumption that some idea or device may eventually allow for such an 
improvement. The results of these simulations are shown in figure 14. 

The NEAs within 0.2 au of the Earth are also within this tolerance. This can be noted from the near- 
Earth views of the 1.2- and 0.8-au heliocentric spheres in figures 15 and 16. The NEAs at 1 au from the 
Earth are generating S/N ratios close to 1 , as can be seen by the bright red splotch on the near-Earth view 
in figure 17. 
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Near Earth 


Far side 



Figure 15. Sensitivity for a 0.8-au heliocentric sphere with 45° half-angle (top) and 5° half-angle (bottom). 



Zenith 


Nadir 


Near Earth 


Far side 



Figure 16. Sensitivity for a 2-au heliocentric sphere with 45° half-angle (top) and 5° half-angle (bottom). 
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Zenith Nadir Near Earth Far side 



Figure 17. Sensitivity for a 1.2-au heliocentric sphere with 45° half-angle (top) and 5° half-angle (bottom). 


The Synergistic Engineering Environment. The limitation of the Coverage/Sensitivity Tool is that the 
NEO motion cannot be modeled. Also, the position and orientation of the detectors is fixed once the 
detector schedule is read in. The SEE addresses these issues by allowing the user to import data sets of 
classical orbital elements to define two-body keplerian orbits for many thousands of objects. The SEE 
user also has interactive control of the detector placement in orbit or on the surface of a planet or moon. 

In figure 18, a screen capture of a survey simulation in progress in the SEE is shown. The current 
release supports the ability to import up to 25 000 minor planets using orbit data read from a text file (the 
upper limit of the object population may be higher depending on the system hardware). All these objects 
can be scaled and tethered to for visualization purposes. Figure 19 is a view from the bore sight of one of 
the detectors, with several NEOs (pyramid shaped objects) in view. 

At present, the list of objects to be loaded into the scene is specified at application launch time by 
selecting an SEE mission from a file browser dialog box. The mission file also specifies the number and 
type of crafts to be loaded into the scene. The ability to interactively import a single object or a collection 
of objects into the scene at any time is a planned near-term enhancement. The craft objects can be placed 
in orbit around or on the surface of any planet in the solar system. Code for interactively modifying the 
orbits of various craft is in place. The properties of the detectors, physical properties of the NEOs, and 
the parameters of the scanning algorithm have been hard coded into this version of the application in 
order to conduct testing. Further enhancements are planned to support the automatic generation of effi- 
cient scanning algorithms for a given configuration of detectors and to modify the parameters of the 
detectors. 

A short report that lists by name the NEOs currently in the field-of-view (FOV) of each of the tele- 
scopes is available at any time step (fig. 20). Additionally, a complete survey analysis can be launched 
via the survey simulation wizard. The wizard prompts the user for the survey start time, survey end time, 
frame integration time, and a radius at which to record the coverage map. Once the parameters are 
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Figure 18. SEE application screen: survey simulation in progress. 



Figure 19. View from detector. 
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Figure 20. Quick survey report with one NEO in FOV. 

accepted, a survey analysis thread is launched, and a progress bar displays the completion percentage. 
During the full survey analysis an interactive coverage map is displayed (fig. 21). The map depicts areas 
of the target sphere that have been covered by the detectors in the survey. The dotted grey lines represent 
lines of latitude and longitude of the target sphere in a sinusoidal projection. The central horizontal line 
represents the target sphere equator, and the top and bottom points of the projection represent the north 
and south poles of the target sphere. Blue rectangles with black outlines are drawn in areas of the map 
corresponding to areas of the target sphere that have been “covered” by the detectors. An area is consid- 
ered covered if it has been inside the detector view frustum while the detector was collecting data. The 
map view may be browsed while the analysis is running by using pan and zoom functions in the map 
window. The native resolution of the bitmap is 3600 x 1800 pixels. 
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Figure 2 1 . Interactive coverage map. 
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The purpose of the interactive coverage map is to give the user immediate qualitative feedback on the 
effectiveness of the proposed scanning strategy. The algorithm for drawing the coverage map employs an 
intersection technique to find the points at which the corners of the rectangular detector view frustum 
intersect the target sphere. These points are used to draw a filled blue rectangle with a black outline on 
the coverage map. This intersection algorithm is computationally efficient and does not noticeably 
impact the speed of the simulation. However, because the edges of the filled rectangle are straight lines 
rather than sphere segments, the map is an approximation of the actual coverage. For view-frusta larger 
than those being considered here, a sphere pixelization technique would provide more accurate results at a 
much greater computational expense. For efficiency reasons, the overcoverage of the target sphere is not 
directly measured in this algorithm. However, a qualitative sense of the amount of overcoverage may 
be gained by examining the density of the black outlines drawn around the blue-filled rectangles (see 
fig. 22). Areas of substantial overcoverage will have more closely spaced black lines. 

The coverage map does not account for data-taking exclusion zones caused by light from the Sun or 
by physical occlusions of the detector view by planets and moons. The Coverage/Sensitivity Tool can be 
used to examine these effects if desired. 


When the survey is complete a series of reports are written. These include one report file for each 
detector in the scene and one summary report file. The detector reports contain a review of the detector 
and survey parameters and a list of observed NEOs at each time step in which at least one NEO was in the 
telescope FOV. The summary report lists how many NEOs were never detected during the survey and 
lists those objects by name. These reports include measured S/N and per-pixel S/N values for each obser- 
vation, as well as survey statistics. Future enhancements include the ability to consider exclusion zones 
for a detector FOV caused by bright objects such as the Sun or Jupiter, or by physical blockages by 
objects obstructing the view cone or frustum. 



Figure 22. Case 1 target sphere coverage map. 
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Impact Simulations 

To follow is a description of the current and planned capabilities of the SEE that relate to conducting a 
CAPS impact simulation. A simulated Earth imp actor being viewed from two vantage points as part of 
an impact analysis is shown in figure 23 (note that the impactor scale is greatly exaggerated in the right- 
hand image). At present, the SEE allows a user to create an impacting asteroid by loading a trajectory file 
that contains position versus time, or position and velocity versus time data. It is assumed that if the 
object being imported is identified as an impactor, the trajectory data describe a path that intersects the 
ecliptic at 1 au. If the Earth is defined as having a zero eccentricity, zero inclination orbit with the semi- 
major axis at exactly 1 au, algorithms in the SEE will be able to assign an epoch to the NEO trajectory 
data that will cause an Earth impact in an arbitrary simulation year. If the simulated Earth orbit does not 
exactly meet the above parameters, the epoch will still be resolved for a closest Earth approach but may 
not generate an impact. 



Figure 23. Earth impactor. 


Future enhancements are planned that will allow the user to create a minor planet that impacts the 
Earth or another planet at any selected date, without requiring the user to supply trajectory data. 

A POD analysis is conducted in the current version of the SEE by first creating one or more CAPS 
observatories and then one impacting NEO. Selecting “precision orbit determination” from the analysis 
pull-down menu will then launch the POD wizard, which guides the user through the process of inputting 
the required parameters. Among the required parameters is the date of the first observation of an NEO by 
observatory. If the user prefers to gauge the first observation opportunity in terms of distance to the 
object from the observatories rather than by selecting a date, a range GUI is provided under the tools pull- 
down menu. The range GUI displays the current distance between any two objects in the scene. The user 
may initially adjust the simulation time controls until the range GUI reports the desired distance at which 
to begin the observations; then the user includes the corresponding date to populate the date field of the 
POD wizard. 
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When the POD wizard is completed, a POD analysis thread is launched to collect the data required for 
the POD report. The POD report contains time stamped data describing the location of the observatories, 
the direction of the NEO with respect to these observatories, and the position and velocity of the NEO. 
The POD report file can be read directly into the Matlab®/Simulink® POD system used to generate the 
reconstructed trajectories and the erroneous predicted miss distance (EPMD). Future enhancements are 
planned that will allow the reconstructed trajectories and an error ellipsoid (a metric designed to indicate 
the margins of error associated with the collections of reconstructed trajectories) to be imported into the 
SEE and visualized. 

Preliminary Results 

To follow are results given for some preliminary survey simulations. The basic scanning algorithms 
used in these examples are intended primarily to show how the SEE environment can be used to compare 
the performance of various CAPS configurations using different NEO data sets. The first configuration 
examined will be a nonrealistic configuration in which the CAPS detectors are fixed inertially in space 
at the center of the target sphere (this location is the center of the Sun in the SEE space.) This case is 
intended to serve as a baseline to isolate the effects of the craft location and orbit motion on the effective- 
ness of the scan. The second configuration consists of two detectors in orbit about the Sun at a radius of 
1 au. The third configuration consists of two detectors located on the Moon. 

Case 1: Nonorbiting Detectors 

In this case, two CAPS telescopes are fixed inertially at the center of the Sun. Each telescope contains 
a detector with a 1° square FOV. The stare-slew scan proceeds by slewing the detector to the target 
location and holding the detector fixed for the stare duration. The scan pattern moves the detector in an 
elevation sweep from the north celestial pole to the south celestial pole. In between each elevation sweep, 
an azimuth clock is performed to move the detector to a new celestial longitude. Figure 24 illustrates the 
scanning pattern. The view at left is looking down toward the south celestial pole and shows the detector 
FOV cones as black lines. The view at right illustrates the motion of the detector boresight as it performs 
an elevation sweep. The black circles are positions at which a stare occurs. The pattern also provides 
for a 5 -percent overlap of the adjacent areas of the scan at the celestial equator. This scan 
requires ~45 days to cover the entire celestial sphere. This simple scanning algorithm produces a large 
amount of undesirable overcoverage as the detector moves toward the poles (an alternative scanning 
algorithm with less overcoverage is also be examined). 


Scan geometry 



Elevation sweeps from pole to pole 
with azimuth clock after each sweep 

Overcoverage of 5 percent at equator 


Figure 24. Case 1 initial scanning pattern. 
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The detector instrument is a telescope equipped with a charged-coupled device (CCD) array of pixel 
dimensions of 32000 x 32000. Additional detector properties are as follows: 


Telescope optical diameter, m 

3.20 

Focal length/optical diameter, f/# 

5.20 

Resolution, arcsec/pixel 

0.10 

Quantum efficiency 

0.80 

Optical efficiency 

0.80 

Integration time, s, or dwell time 

90.00 


The first NEO data set used in this case consisted of 8988 external returning comets (ERCs) with 
semimajor axes ranging from 33 to 10000 au and absolute magnitude ranging from 9.2 to 19. This data 
set was provided by Dr. William Bottke of Southwest Research Institute based on reference 2. These are 
simulated objects that were created using methods designed to produce realistic orbits based on known 
comets (ref. 3). None of the simulated objects is designed to necessarily impact the Earth. Each object 
was assigned an identical physical property as follows: 


Diameter 

1 km 

Albedo 

0.02 

Photometric slope 

0.15 


The true anomaly of each object was set such that its heliocentric distance on the date that the scan 
begins was approximately 9 au (see fig. 25). 



Figure 25. Visualization of ERC set at start of scan. The gridded sphere marks a heliocentric distance of 9 au. The 
density of the objects appears isotropic. 
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The summary report information generated by the SEE at the completion of this simulation is shown 
below: 


Number of targets: 8988 

Targets not scanned: 1 

Targets with low per-pixel S/N (<6): 0 

Total undetected targets: 1(0.01 1 1259 %) 

Signal-to-Noise Ratios 

Highest: 11.1409 Lowest: 8.63558 Average: 10.3474 

Per-Pixel Signal-to-Noise Ratios 
Highest: 7.87783 Lowest: 6.10628 Average: 7.31668 

Number of scopes: 2 

Survey start date: 2000 01 01 00:00:00.000 
Survey duration, days: 44.3345 
Frame integration time, s: 90 
Run time: 4 hr, 9 min, 35 s 

Targets not scanned: 
z_6059 

Figure 22 includes the final coverage map. All areas of the target sphere have been covered by the 
scan. The high density of black outlines near the poles of map relative to a similar area at the equator 
indicates the severe overcoverage at high and low latitudes (see insets). 

The “targets not scanned” category in the survey summary report refers to the number of objects never 
found in the FOV of any of the CAPS detectors. In this case, because our scan covered the entire celestial 
sphere, this could happen only if the NEO moved into a previously visited area of sky before the NEO’s 
original location had been visited. Review of the simulation graphics showed that object “z_6059” had 
indeed been located just west of the eastward-moving detector at the start of the simulation. By the end of 
the scanning period, the object had moved eastward into a previously covered area of sky. This object 
would have been observed within the first several hours if the scan had been allowed to repeat. 

The “targets with low per-pixel S/N” category refers to objects that were scanned but would have gone 
undetected due to low per-pixel S/N ratio. In this example the cutoff value has been set to 6.0. The total 
S/N ratio for an object is a measure of the mean number of photons per unit time received by the detector. 
The per-pixel S/N ratio takes into account the number of pixels on the CCD over which this signal will be 
spread (a minimum of 1 pixel). An object with a higher angular rate relative to the detector will reduce the 
per-pixel S/N reading. 

These preliminary results indicate that the detector parameters appear to be sufficient for observing 
1-km ERCs with the given orbits and physical parameters. To examine the effect of faster moving NEOs, 
the case was repeated with a new object data set consisting of 8268 ERCs with true anomaly adjusted so 
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that the heliocentric distance was approximately 5 au. An excerpt from the summary report for this run is 
below: 

Number of targets: 8268 

Targets not scanned: 21 
Targets with low S/N (<6): 0 

Total undetected targets: 21(0.253991 %) 

Signal-to-Noise Ratios 

Highest: 40.8559 Lowest: 28.6865 Average: 35.3438 

Per-Pixel Signal-to-Noise Ratios 
Highest: 28.8895 Lowest: 14.5187 Average: 22.7721 

In this case, 21 objects move in such a way as to avoid the scan pattern. Figure 26 shows a view of the 
objects looking toward the south celestial pole. These objects move in a clockwise direction, effectively 
following behind the detectors as they also move clockwise. The circle marks a radius of 1 au. 

The next experiment utilizes a collection of 9001 simulated NEAs as the target set. These objects 
were also provided by Dr. William Bottke. The semimajor axis of these objects ranges from 0.4 to 
7.4 au, and visual magnitudes range from 13.2 to 22. Figure 27 is a visualization of the object distribu- 
tion, which shows a majority of low-inclination orbits. 



Figure 26. View of missed objects. 



Figure 27. NEA distribution: View along ecliptic (left) and from the north celestial pole (right). 
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A repeat of the scanning simulation produced the following report: 

Number of targets: 9001 

Targets not scanned: 889 

Targets with low per-pixel S/N (<6): 9 

Total undetected targets: 898(9.97667 %) 

Signal-to-Noise Ratios 

Highest: 172158 Lowest: 5.28778 Average: 435.808 

Per-Pixel Signal-to-Noise Ratios 
Highest: 3402.03 Lowest: 3.73903 Average: 76.3751 

A review of the visualization showed the majority of the nearly 900 unscanned objects were missed 
because their high velocities allowed them to pass between subsequent elevation sweeps in the scanning 
pattern. The nine objects with less than the minimum required per-pixel S/N ratio had absolute magni- 
tudes greater than 19. 

The last experiment in this case incorporated a new scanning strategy designed to reduce the over- 
coverage at areas near the poles. This strategy sweeps through arcs in azimuth with an elevation clock 
after every azimuth sweep. The scan starts at the north celestial pole and ends at the south celestial pole. 
The length of the azimuth arc is adjusted for the current elevation of the scan. The arc length is zero at 
the poles and largest at the celestial equator. The scan also incorporates a 5 -percent coverage overlap 
at the equatorial azimuth sweep. A schematic of the scan strategy is shown in figure 28. The coverage 
map for this scan is shown in figure 29. Comparison of this map with figure 22 shows the reduced over- 
coverage of the poles for the azimuth-sweep strategy. 

The improved scanning efficiency is reflected in the survey duration, which has been reduced from 
44.3 days for full coverage for the elevation-sweep scan to 28.3 days for the azimuth-sweep scan. The 
results of a simulation using the improved scan strategy against the same NEA object data set are 
excerpted here from the summary report: 

CAPS Survey Summary 

Number of targets: 9001 

Targets not scanned: 81 

Targets with low per-pixel S/N (<6): 9 

Total undetected targets: 90(0.999889 %) 

Signal-to-Noise Ratios 

Highest: 98052.7 Lowest: 5.29113 Average: 440.672 

Per-Pixel Signal-to-Noise Ratios 
Highest: 3093.17 Lowest: 3.74139 Average: 81.9013 

Number of scopes: 2 

Survey start date: 2000 01 01 00:00:00.000 

Survey duration, days : 28.3514 

Frame integration time, s: 90 

Run time: 2 hr, 34 min, 30 s 
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Figure 28. Scanning pattern using azimuth sweep. This view is looking down toward south pole of target sphere. 
The number of stare points in an azimuth sweep increases as elevation goes from pole to equator. 



Figure 29. Survey map for azimuth-sweep scan pattern. 

Also interesting is the substantially reduced number of unscanned objects (81 here versus 889 in the 
elevation- sweep strategy). Likely causes could be that the reduced time between subsequent passes of the 
azimuth sweep reduce the possibility of the NEO traveling far enough to evade detection, or that the 
azimuth sweeps are better aligned with the object trajectories. The nine low-signal objects are the objects 
with magnitudes greater than 19. 

Case 2: Two-Location System 

In this case, a detector is located on each of two crafts orbiting the Sun at 1 au. The scanning pattern 
is similar to the elevation-sweep method used at the start of case 1, but is adjusted for the fact that each 
detector in the two-location system needs to sweep over its local north and south poles in order to view 
the poles of the sun-centered target sphere. In figure 30, the left view shows the posigrade 1-au orbits of 
the two crafts, with the craft starting and ending positions as unfilled circles. The filled black circles 
indicate the positions of the crafts when the scan is at opposition. The right view shows that the elevation 
sweep spans more than 180° in order to cover the poles of the sun-centered target sphere. 
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Scan geometry 



Elevation sweeps over local poles with 
azimuth clock after each sweep 


Overcoverage of 5 percent at equator 


Figure 30. Two-location system scanning pattern. 



Figure 31. Coverage map for two-location system, elevation-sweep scan, 9-au target sphere. 

The coverage map for this pattern is shown in figure 31. Note that because the detector locations are 
offset from the target sphere origin, the radius of the target sphere will affect the amount of coverage 
registered by the map. While this effect can be mitigated by selecting a “celestial” sphere with infinite 
radius, the coverage of such a sphere is not necessarily a desirable metric for the CAPS system. Because 
the NEOs of interest are within approximately 9 AU, the desirable metric will be one that indicates the 
volume of space covered by the detectors in this region. To examine the coverage at other heliocentric 
distances, the simulation can be programmed to produce multiple maps, although with increasing expense 
in simulation time and memory usage. Because of these difficulties, selecting a method for measuring the 
combined coverage of a two-location system in the space near the detectors will be an important design 
consideration for further CAPS survey simulations. 

The NEOs used in this run were the ERCs in case 1 whose heliocentric distances were approximately 
9 au at the beginning of the scan; therefore, a single 9-au sun-centered target sphere was used. The scan 


188 



Figure 32. Coverage map for two-location system, 180° elevation span. 


was terminated when the elevation sweeps had covered all longitudes along the equator. The wedge- 
shaped gaps in the map are an effect of the off-opposition scanning geometry, where the north-to-south 
motion of the detector was not corrected to maintain alignment with the lines of longitude on the target 
sphere. Subsequent repeats of the scan will tend to fill in these gaps as the motion of the craft causes the 
scan opposition point to move. 

In this case, 204 objects were not scanned due to the gaps in coverage. No objects had less than the 
minimum S/N ratio of 6.0. The scan took 51 days to complete the coverage at the equator. 

This simulation was also run using the 5-au ERCs and a subset of NEA objects used in case 1 (the 
reduced NEA set contains only objects with absolute magnitude greater than 19.1). Again it was seen that 
the faster moving objects caused an increasing number of missed sightings. Of the 8268 ERCs at 5 au, 
461 were unscanned. Of the 2383 NEAS, 892 were not scanned and two objects had low per-pixel S/N 
measurements. 

The azimuth-sweep scanning strategy used to reduce overcoverage at the celestial poles was also 
attempted in this case. Figures 17 and 15 show the coverage results for two versions of the azimuth- 
sweep strategy. In figure 32, the azimuth-sweep span is 180° of the elevation on a sphere centered at the 
detector. The 1-au distance from the detector location to the 9-au sun-centered target sphere origin causes 
the gaps in the target sphere coverage. Figure 33 includes the results of adjusting the scan to cover 
200° of elevation at the local sphere in order to get better coverage of the 9-au sun-centered target sphere. 
The duration of the scans shown in figures 32 and 33 were 28 and 31 days, respectively. 
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Figure 33. Coverage map for two-location system, 200° elevation span. 


Case 3: Two Detectors on the Surface of the Moon 

The geometry of this CAPS survey configuration is shown in figure 34. The view at left shows the 
view from the Moon’s equator of the elevation sweeps. The view at right shows the visualization graph- 
ics of the scaled-up Moon bases and the detector view frusta. The two detectors are located on the Moon 
surface at 75° north and south latitude. The north detector is at 90° east longitude, and the south detector 
is at 90° west longitude. Each moon-based detector is performing an elevation sweep designed to cover 
the northern or southern hemisphere of a 9-au target sphere centered at the Sun. The rotation of the Moon 
itself is used to change the azimuth of the detector, so no azimuth clock is performed. The scan was 
terminated after 28.5 days. The coverage map (fig. 35) illustrates that the azimuth rate introduced by the 
Moon’s rotation is too large to allow full coverage at the equator. To improve coverage at the equator, 
the elevation-sweep scan pattern must reduce coverage at the poles or use a smaller dwell time or a larger 
view frustum. 

The coverage results for an alternative configuration with the detectors located directly on the lunar 
poles, each using an azimuth-sweep scan to cover half of the sun-centered 9-au target sphere, are given in 
figure 36. A full 360° azimuth sweep is performed at each elevation. After a complete azimuth sweep, 
an elevation clock of 0.95° is performed and a new azimuth sweep is started. The duration of the survey 
was 28.5 days. Overall coverage appears improved over the elevation-sweep scan. Small horizontal 
strips of missed coverage are caused by the rotation of the Moon. Revision of the scanning program to 
account for this effect could provide 100-percent coverage with little additional scanning time. The effect 
of occlusion of the detectors by the Earth will, however, substantially affect the real coverage results near 
the lower scan elevations. 

The scan shown in figure 36 was performed on the collection of 2383 NEAs used in case 2. Sixty of 
the objects were unscanned and two were missed due to low signal. This result is consistent with the 
trend that patterns sweeping generally along lines of latitude (azimuth sweep) rather than lines of longi- 
tude (elevation sweep) have been more effective in reducing the number of missed NEAs. 
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Overcoverage of 5 percent at equator 


Figure 34. Moon-based system scanning pattern. 



Figure 35. Coverage map for moon-based detectors with elevation- sweep scan. 



Figure 36. Coverage map for moon-based detectors with azimuth- sweep scan. 
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Concluding Remarks 

The beginnings of an integrated Comet/Asteroid Protection System (CAPS) simulation and visualiza- 
tion tool have been constructed in the Synergistic Engineering Environment (SEE) application. The 
availability of interactive three-dimensional views of the scene geometry assists in evaluating the effec- 
tiveness of proposed detection systems and in improving their designs. The preliminary examination of 
several proposed survey configurations against simulated near-Earth object (NEO) data sets showed the 
ability of the SEE to compare the efficiency of different scanning algorithms. The problem of designing 
an effective scanning algorithm was shown to be closely tied to the problem of establishing a valid survey 
coverage metric when the system contains more than one detector location. It was demonstrated that a 
scan pattern achieving full coverage of a given area on a target sphere can miss substantial numbers of 
fast moving objects due to the objects’ motion between subsequent passes of a sweeping-style scan. To 
counter this effect, a successful scanning pattern should consider the geometry of the object paths. 

The future development of the SEE for CAPS would benefit from addition of the following features: 

• Sophisticated scanning algorithms that allow multiple craft to work together to provide full cov- 
erage of the target volume with minimum overcoverage. 

• Modeling of survey detector frustum occlusion by solid objects or light sources. 

• Volume rendering of the coverage map showing overcoverage at all distances between a mini- 
mum and maximum radii of the target coverage volume. 

• Near-Earth object-creation routine to automatically create object trajectories that will impact the 
Earth at a user specified date. 

• Further integration with the Coverage Analysis Tool separate from the SEE used in the orbit de- 
termination and orbit modification sections of this report. 
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